Платёжный шлюз ложится не от объёма атаки, а от таймаута, выставленного на два уровня выше него. Когда на онлайн-кассу идёт L7 DDoS или шквал ботов долбит эндпоинт оплаты, первым сдаётся не приложение, а цепочка ожиданий: балансировщик, reverse proxy, SSL-терминация, upstream. Если таймаут на периметре больше, чем терпение самого шлюза, под нагрузкой платежи начинают падать по timeout, а не по атаке. Клиент видит “ошибка оплаты”, касса не получает подтверждение, а в логах пусто: запрос просто не дожил до бэкенда.
Дальше включается второй эффект. Из-за неверных таймаутов защита от ботов и WAF-блокировки срабатывают ложно: живые покупатели с медленным мобильным интернетом отваливаются по тем же правилам, что и флуд. Конверсия сайта падает на ровном месте, лидогенерация в магазине просаживается, а служба поддержки разбирает жалобы на “платёж не прошёл”. При этом атака может быть уже отбита на уровне L7 DDoS, и никто не поймёт, что реальная причина отказов сидела в конфиге nginx и настройках upstream.
Ниже чек-лист, по которому стоит пройти всю цепочку: от балансировщика и SSL-терминации до приложения платёжного шлюза. Отдельно разберём правило согласования таймаутов reverse proxy и самого шлюза, а также то, чем заменить Cloudflare, когда нужен российский аналог Cloudflare с предсказуемым поведением под нагрузкой, включая TrafficVeil.
Почему таймауты – критическая точка отказа платёжного шлюза под DDoS
Платёжный шлюз под DDoS-атакой редко падает целиком. Чаще он деградирует: часть запросов проходит, часть отваливается по timeout, а часть зависает в очереди настолько, что клиент уходит к конкуренту. Именно таймаут определяет, где проходит граница между “сайт тормозит” и “мы потеряли деньги”. И настраивают его в 90% случаев наугад.
Смотрите, что происходит физически. Клиент нажимает “Оплатить”, браузер открывает TLS-соединение, отправляет POST в платёжный шлюз. Дальше запрос идёт через балансировщик, reverse proxy, веб-сервер, приложение, потом наружу в банк-эквайер или процессинг. На каждом стыке есть свой таймаут. Если хотя бы один из них короче реального времени ответа под нагрузкой, платёж отвалится с ошибкой 504, хотя деньги могли бы списаться через секунду.
Что делает атака с таймаутами
L7 DDoS не ломает сервер, он заполняет пул воркеров и соединений. Когда 20 000 ботов одновременно держат открытые сессии, каждый новый запрос ждёт освобождения потока. Время ответа растёт нелинейно: с 200 мс до 3 секунд, потом до 15, потом до бесконечности.
Дальше вступает эффект каскада. Reverse proxy отдаёт 504 через 30 секунд, балансировщик считает узел мёртвым и выкидывает его из пула, приложение получает шквал ретраев от клиентов, которые видят ошибку и жмут “Оплатить” повторно. Нагрузка удваивается. Итог: система, которая технически выдержала бы атаку, ложится от собственных таймаутов и повторных попыток.
Второй сценарий ещё коварнее. Таймаут на SSL-терминации стоит 60 секунд, а приложение отвечает за 5. Под атакой приложение начинает отвечать за 70. Соединение рвётся на уровне TLS, клиент получает сетевую ошибку, в логах платёжного шлюза чисто, а конверсия сайта падает на 40%. Никто не понимает, что случилось, потому что “шлюз же не падал”.
Ложные срабатывания защиты
Слишком агрессивные таймауты при защите от ботов дают обратный эффект. Если WAF-блокировки срабатывают по поведенческому признаку, а таймаут на проверку challenge стоит 2 секунды, под нагрузкой челлендж не успевает пройти даже легитимный клиент. Начинаются отказы в платежах от живых людей, а боты как раз проходят, потому что они терпеливее.
Типичная картина: интернет-магазин включает защиту, таймауты не трогает, и получает 15-20% отказов на пике. Аналитика показывает рост “брошенных корзин”, служба поддержки тонет в жалобах, а виновата одна цифра в конфиге nginx, которую никто не проверял год.
Почему это критично именно для платёжных шлюзов
У платежей жёсткая семантика. Нельзя “попробовать ещё раз” вслепую: повторная отправка платежа без идемпотентного ключа может списать деньги дважды. Нельзя отдать клиенту таймаут, если операция уже ушла в банк. Нельзя держать соединение открытым 5 минут, потому что клиент уйдёт.
Окно между “успели” и “не успели” измеряется секундами. Платёжный шлюз под атакой живёт в этом окне, и таймауты это единственный инструмент, который определяет, с какой стороны вы окажетесь. Настраивать их нужно до атаки, а не во время, когда нагрузка уже выросла и каждая правка конфига рискует уронить прод.
Ниже разберём чек-лист проверки таймаутов на всех уровнях: от балансировщика до приложения, включая SSL-терминацию и согласование с upstream.
Чек-лист проверки таймаутов на всех уровнях инфраструктуры
Аудит таймаутов – это не разовая акция, а процедура, которую стоит прогонять перед каждым пиковым периодом: распродажи, праздники, отчётные даты. Ниже чек-лист, по которому мы проверяем платёжные шлюзы, когда клиент жалуется на “платежи отваливаются под нагрузкой”.
Шаг 1. Балансировщик. Смотрим четыре параметра: connect timeout, read timeout, keepalive timeout и health check interval. Connect timeout выше 5 секунд для внутренней сети – почти всегда ошибка: если бэкенд не ответил за 3-5 секунд, он либо перегружен, либо мёртв, и держать соединение нет смысла. Keepalive на балансировщике должен быть меньше, чем на upstream-сервере, иначе балансировщик будет переиспользовать уже закрытые соединения и ловить 502. Проверьте, что health check не бьёт по эндпоинту, который сам ходит в платёжный провайдер – иначе при внешнем сбое у вас отвалится весь пул.
Шаг 2. Reverse proxy. Здесь живут самые дорогие ошибки. Проверяем proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout и keepalive_timeout. Значение proxy_read_timeout должно быть больше, чем максимальное время обработки запроса в приложении, но меньше, чем таймаут на стороне платёжного шлюза (об этом в следующем разделе). Если proxy_read_timeout стоит 60 секунд, а платёжный шлюз отвечает максимум за 25, вы держите воркеры занятыми впустую и теряете пропускную способность ровно тогда, когда она нужна.
Шаг 3. SSL-терминация. Отдельная зона риска. Проверьте ssl_handshake_timeout: он не должен быть больше 5-10 секунд, иначе медленные клиенты и боты будут занимать слоты на рукопожатии. Убедитесь, что сессионный кеш включён (ssl_session_cache shared:SSL:10m), а OCSP stapling не ходит в интернет на каждый запрос. Для платёжного шлюза критично: если терминация SSL происходит на отдельном узле, добавьте таймаут на весь путь до бэкенда, а не только на рукопожатие.
Шаг 4. Веб-сервер. У nginx это client_header_timeout, client_body_timeout, send_timeout. Значения по умолчанию (60 секунд) для платёжного API слишком щедрые: тело запроса на оплату редко превышает несколько килобайт. аналог cloudflare offers additional context worth reviewing. Ставьте 10-15 секунд на заголовки и тело, 20-30 на отправку ответа. Для Apache – Timeout и KeepAliveTimeout, причём KeepAliveTimeout должен быть больше, чем интервал между запросами от платёжного провайдера, иначе будут рваться keepalive-соединения.
Шаг 5. Приложение. Самый частый провал: таймаут на HTTP-клиент к платёжному провайдеру выставлен по умолчанию (бесконечность или 300 секунд). Ставьте connect 3-5 секунд, read 10-20 секунд, общий дедлайн на всю операцию 25-30 секунд. Добавьте retry с экспоненциальной задержкой, но только для идемпотентных запросов, иначе получите двойные списания.
| Уровень | Параметр | Разумное значение | Что ломается при превышении |
|---|---|---|---|
| Балансировщик | connect timeout | 3-5 с | Слоты заняты мёртвыми бэкендами |
| Reverse proxy | proxy_read_timeout | 15-30 с | Воркеры висят на медленных запросах |
| SSL-терминация | ssl_handshake_timeout | 5-10 с | Боты занимают слоты рукопожатием |
| Веб-сервер | client_body_timeout | 10-15 с | Slowloris-атака проходит незамеченной |
| Приложение | HTTP-клиент к провайдеру | 25-30 с общий | Двойные списания при retry |
После правок обязательно прогоните нагрузочный тест с искусственной задержкой на стороне платёжного провайдера. Если при задержке 20 секунд платежи падают по вашему таймауту, а не по таймауту провайдера – вы нашли точку отказа. Зафиксируйте все значения в конфигурации как код, иначе через месяц кто-то “временно” вернёт 60 секунд и всё сломается снова.
Согласование таймаутов reverse proxy и платёжного шлюза: главное правило защиты
Большинство отказов в платежах во время DDoS случается не потому, что атака пробила защиту, а потому, что таймауты на периметре выставлены длиннее, чем внутри платёжного шлюза. Логика простая: если reverse proxy или SSL-терминатор ждёт ответа дольше, чем сам шлюз, то под нагрузкой клиент получает 504 от прокси, хотя бэкенд уже отказал раньше и вернул понятную ошибку. В логах это выглядит как атака, хотя на деле это рассинхрон настроек.
Правило, которое стоит зафиксировать в конфигурации: любой таймаут на внешнем контуре (proxy_read_timeout, timeout server в HAProxy, proxy_connect_timeout, ssl_handshake_timeout) должен быть строго меньше соответствующего таймаута внутри платёжного шлюза. Разница в 1-3 секунды даёт буфер, за который прокси успевает получить честный ответ или ошибку от шлюза и корректно её транслировать клиенту.
Как согласовать значения на практике
Начните с инвентаризации. Выпишите все таймауты, которые участвуют в пути платежа: от TCP-соединения на балансировщике до запроса в базу данных внутри платёжного ядра. Обычно их 6-8 на каждый узел, и расхождение хотя бы в одном ломает всю цепочку.
- SSL-терминация. ssl_handshake_timeout держите в пределах 5-10 секунд. Если клиент не завершил handshake за это время, это либо мобильная сеть с потерями, либо попытка исчерпать ресурсы на шифровании. Продление до 30-60 секунд открывает дорогу для slow-handshake атак.
- proxy_connect_timeout. 2-5 секунд. Установка соединения с бэкендом в пределах ДЦ не должна занимать дольше. Если занимает, проблема в самом шлюзе, а не в сети.
- proxy_read_timeout и proxy_send_timeout. Здесь ключевое: они не должны превышать внутренний таймаут обработки платежа. Если шлюз обрабатывает транзакцию максимум за 15 секунд, ставьте на прокси 12-13 секунд.
- keepalive_timeout. 60-75 секунд для клиентских соединений, 15-30 секунд для upstream. Слишком большой keepalive держит воркеры занятыми под атакой.
- client_body_timeout и client_header_timeout. 10-15 секунд. Медленная отправка тела запроса – классический вектор Slowloris-подобных атак на платёжные формы.
- Таймаут в самом платёжном шлюзе. Должен быть больше, чем на прокси, но не бесконечным. Типично 20-30 секунд для синхронных операций и отдельные значения для асинхронных callback.
После настройки обязательно проверьте связку под нагрузкой. Прогоните нагрузочный тест с задержкой ответа бэкенда на 80-90% от установленного таймаута. Если прокси начинает рвать соединения раньше, чем шлюз успевает ответить, вы получите ложные отказы именно в пиковые моменты, когда каждый платёж на счету.
Отдельный момент – поведение при ретраях. Если прокси настроен повторять запрос при таймауте, а платёжный шлюз не идемпотентен по ключу транзакции, вы получите двойные списания или зависшие холды. Ретраи включайте только для идемпотентных операций и с явным ограничением по количеству попыток.
Ещё одна ошибка – одинаковые таймауты для всех типов запросов. Платёжная форма, callback от банка и запрос статуса транзакции имеют разную допустимую длительность. Разделите location-блоки или используйте отдельные upstream с разными значениями. Для callback от эквайринга таймаут можно поднять до 30 секунд, для пользовательской оплаты – держать в районе 10-15 секунд, иначе клиент уйдёт с формы раньше, чем получит ответ.
Финальная проверка: сверьте таймауты на всех уровнях после каждого релиза конфигурации. Настройки легко теряются при деплое, особенно если часть параметров задаётся в разных файлах или через переменные окружения. Ведите единый реестр таймаутов и проверяйте его перед выкаткой в прод. Это занимает 10 минут, но экономит часы разбора инцидентов, когда платёжный шлюз падает не от атаки, а от собственной конфигурации.
Выбор российского аналога Cloudflare для защиты платёжного шлюза
Когда таймауты на всех уровнях сведены в таблицу и проверены, остаётся выбрать платформу, которая будет стоять перед платёжным шлюзом. Здесь российский бизнес в 2026 году упирается в конкретную проблему: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Для интернет-магазина с онлайн-кассой это означает не теоретические риски, а живые отказы в оплате: клиент жмёт “Оплатить”, запрос уходит на зарубежный edge, теряется, возвращается 522 или 524, и заказ не оформляется. Потерянная на этом шаге конверсия сайта стоит дороже любой подписки.
Зависимость от зарубежной инфраструктуры создаёт и второй слой рисков: регуляторные требования к персональным данным плательщиков, невозможность предсказуемого SLA, отсутствие нормальной техподдержки в часовом поясе Москвы. Поэтому вопрос “чем заменить Cloudflare” для платёжного контура решается не по цене, а по критериям. Их немного, но каждый проверяется руками.
- Терминация SSL на стороне РФ. SSL-сертификат должен выпускаться и обслуживаться внутри страны, а не через зарубежный API. Проверьте, поддерживает ли платформа ACME-автообновление и что происходит, когда сертификат истекает в 3 часа ночи.
- Управляемые таймауты. Ключевой критерий. Платформа обязана позволять задать connect timeout, read timeout и idle timeout отдельно для каждого upstream и не переписывать их “по умолчанию”. Если таймауты зашиты в конфиг и не настраиваются, под L7-атакой вы получите каскад 504 вместо управляемого сброса.
- L7 DDoS и защита от ботов без влияния на честный трафик. Платёжный шлюз получает POST-запросы от платёжной системы, а не от браузера. Если WAF-блокировки или антибот-модуль режет их по эвристике, вы теряете подтверждения оплаты. Нужны белые списки по IP и по путям callback-эндпоинтов.
- GeoIP-фильтрация. Возможность разрешить трафик только из РФ и стран присутствия, а остальное отсекать на периметре, не доводя до приложения.
- Reverse proxy с предсказуемым поведением. Прозрачная передача X-Forwarded-For, реального IP и заголовков платёжной системы, иначе логи и антифрод теряют смысл.
- Тарификация. Считаются ли запросы ботов и заблокированные атаки в квоту. На платёжном шлюзе, где атака генерирует десятки тысяч RPS, это разница в разы.
- DNS-сервис и CDN. DNS должен быть отказоустойчивым и находиться в российской зоне, а CDN не обязана кэшировать платёжные страницы, но должна ускорять статику магазина.
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. Для платёжного контура важны три свойства. Первое: таймауты задаются явно на уровне reverse proxy и upstream, поэтому правило “таймаут прокси не больше таймаута шлюза” реализуется без костылей. Второе: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, то есть пик L7-нагрузки не превращается в счёт. Третье: SSL-терминация и DNS работают на территории РФ, что закрывает и регуляторную часть, и проблему доступности из российских сетей.
Практический порядок перехода выглядит так. Сначала аудит таймаутов по чек-листу из предыдущих разделов и фиксация текущих значений в таблицу. Затем перенос DNS на TrafficVeil с низким TTL, чтобы откат занимал минуты. Дальше включается reverse proxy в режиме наблюдения: трафик идёт через платформу, WAF и антибот работают в логе, без блокировок. На этом этапе сверяются таймауты: connect 3-5 с, read 10-15 с для API платёжной системы, idle 60 с для keepalive, и главное, значение на прокси не превышает значение на шлюзе. Потом включаются GeoIP-фильтрация и L7-защита, а callback-эндпоинты платёжной системы вносятся в белые списки по IP и пути. Последним шагом добавляется CDN для статики магазина.
TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, и предлагает переход с Cloudflare без простоя: параллельная работа DNS, тестовый период на зеркале, перенос продакшена в окно низкой нагрузки. Аналитика на платформе показывает распределение запросов по странам, долю ботов и время ответа upstream, что даёт возможность ловить просадки таймаутов до того, как они превратятся в отказы по оплате.
Замена Cloudflare на платёжном шлюзе не сводится к смене DNS. Это перенос точки, где принимаются решения о таймаутах, фильтрации и терминации SSL. Если эта точка находится в российской юрисдикции, под вашим контролем и не считает атаки в тариф, платёжный контур перестаёт быть самым хрупким звеном в ИТ-инфраструктуре магазина.
Начните с одного конкретного шага: выпишите текущие значения таймаутов на всех уровнях – на балансировщике, на reverse proxy, на веб-сервере и в самом платёжном шлюзе – и постройте таблицу соответствия. Практика показывает, что в 8 из 10 аудитов находится хотя бы одно расхождение: например, read timeout на прокси выставлен в 120 секунд, а внутренний таймаут шлюза – 30. Под нагрузкой это означает, что соединения висят на прокси, воркеры выедаются, и платежи падают по timeout ещё до того, как атака вообще будет зафиксирована. После того как таблица заполнена, приведите правило: таймаут на внешнем контуре всегда меньше или равен таймауту на внутреннем, с запасом в 3-5 секунд на сетевую задержку.
Второй шаг – проверка SSL-терминации. Если сертификат терминируется на стороне, которая не входит в вашу зону контроля, вы не увидите реальные таймауты рукопожатия и не сможете отличить медленный TLS-handshake от L7 DDoS. Здесь и появляется вопрос, чем заменить Cloudflare: зарубежный сервис ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, поэтому платёжный шлюз на такой инфраструктуре рискует потерять часть клиентов ещё до начала атаки. TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе, что позволяет держать все таймауты и правила в одном месте. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, подходит для сайтов, интернет-магазинов, WordPress и Bitrix и предлагает переход с Cloudflare. Проведите нагрузочный тест с эмуляцией 5-10 тысяч одновременных соединений и убедитесь, что при атаке отказы идут по вашим правилам, а не по таймаутам.
